https://github.com/apache/kafka/pull/17231

故事背景

不知道大家在開發專案的時候有沒有遇過一個情況，有一個類別實在太好用了所以被所有人關注和使用，然後隨時時間推演大家不斷把功能往裡面塞，一直塞一直爽，最後那個肥嫩嫩的類別遍佈整個專案各地，有一天整個專案要重新結構化，但該類別已經成為一個上帝般的存在，導致整個重構卡住 ...

如果你覺得上述劇情很熟悉很老梗，沒錯，Kafka也有這麼一個故事，故事的主角就是KafkaConfig，那麼該類別是如何成為上帝般的存在呢？就我的體感大概有三個原因：

1. 大家開發的時候不想要到處找參數檔，於是通通放在一個檔案裡面
2. 參數之間的互相檢查有時候太難切割，那不如通通放在同一個檔案
3. 有些類別可能會用到很多參數，懶惰就乾脆放在同一個檔案裡

上述原因再加上我沒想到的一路到現在，KafkaConfig明明只是個參數檔卻有著數千行的大小，想當然爾，在Kafka要更模組化的路上，KafkaConfig就成了一顆很大的絆腳石，為了解決這個問題，將KafkaConfig拆分的行為也陸續展開 ... 那麼我們拆分的邏輯是什麼？

解決辦法

首先，我們嘗試將參數分門別類，例如屬於 Quorum的參數我們就獨立一個檔案來放，同時把只屬於Quorum的參數邏輯（包含檢查與getter）也一併移動過去，這樣就可以讓KafkaConfig大幅度的瘦身。

寫到這裏，大家可能會有一個疑問，前面不是說KafkaConfig遍佈整個專案，如果把Quorum相關的邏輯抽到QuorumConfig去了，那麼原本透過KafkaConfig來使用Quorum參數的類別該怎麼辦？沒錯，這是一個好問題，極端一點我們就是來針對Quorum相關的程式碼進行重構，讓他們從原本依賴KafkaConfig轉移到使用QuorumConfig，然而這會有另一個難處是該些類別可能同時也需要其他參數檔，如果該些參數檔還沒分門別類的話，自然也只能從KafkaConfig來拿取，那這個重構就很不重構了，原本只是要一個KafkaConfig現在變成還多要一個QuorumConfig ...

因此在真正終結KafkaConfig之前，我們需要一個暫時的解法，那就是允許KafkaConfig回傳一個QuorumConfig，這樣我們就不需要大規模重構各種建構式或是方法，只需要將KafkaConfig.quorumXX改成KafkaConfig.quorumConfig.quorumXX就好，如此不只降低了要重構的範圍，同時也替未來埋下伏筆，等有一天KafkaConfig退位消失，我們就可以輕鬆的把KafkaConfig移除直接引用QuorumConfig，當然這個做法也不是沒有副作用，看看那精美的呼叫鏈 ...

等等，這樣故事就結束了嗎？當然還沒有，讓KafkaConfig可以回傳QuorumConfig還有一個非常重要的原因，那就是KafkaConfig本身是一個動態的參數！什麼是動態的參數？Kafka作為一個非常貼心的系統，允許使用者在線更改參數，例如你可以提高執行緒的數量且不用下線任何節點，而為了追求這個崇高的理念，Kafka內許多元件都具備重新參數化的能力，而身為參數的化身KafkaConfig自然要具備總是提供最新參數的能力，然而這個能力過於複雜目前無法直接下放到各個參數檔，因此為了讓抽出來的參數檔也能反應當下最新的參數，KafkaConfig可以透過自身反應動態參數的能力，讓從自己生出來的參數檔也總是反應最新的參數 ... 聽起來是不是有點繞口，沒關係，社群上也有人曾經一頭霧水

廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術